\subsection{Signatures}

À la base, nous devions modifier l'application \textbf{Castle Defense}.
Le problème qui s'est rapidement posé est que l'application ne se lançait pas après signature avec une de nos clés.
Ceci s'est expliqué par le fait que l'application possédait une constante permettant de vérifier qu'elle était bien signée par la clé du développeur,
empêchant ainsi toute recompilation par une tierce personne.

Lors d'une séance de travaux pratiques, nous avons pris connaissance d'un moyen de passer outre cette vérification en utilisant une preuve de réalisation
(proof of concept \cite{PoC}) afin de faire passer notre application modifiée pour celle d'origine et ainsi pouvoir l'exécuter sans problème.

Par la suite, cette faille de sécurité a été corrigée sur la plupart des appareils mobiles,
rendant impossible toute modification sur \textbf{Castle Defense}.
D'un autre coté, le PoC n'était pas nécessaire sur l'application \textbf{Checkers},
nous permettant donc de signer simplement l'application avec la clé de debug d'Android.


\subsection{Code Natif}

En décompilant les \texttt{.apk}, nous nous sommes rendu compte que, pour de nombreux jeux sur Android, la majorité du code est contenu dans une librairie écrite en \texttt{C/C++}, et que le code Java ne sert qu'à gérer la publicité et à faire le lien entre Android et les fonctions de la librairie native.

Bien qu'il soit possible de désassembler ces librairies, d'avoir les noms des classes et fonctions en clair, et de modifier les instructions en faisant des modifications hexadécimales, nous avons préféré chercher un jeu qui n'utilise pas de librairie car il est bien plus compliqué de modifier de l'assembleur.


\subsection{Un code obscur}
Après avoir effectué la décompilation de l'apk vers du code en hexadécimal, et ce dernier vers du code java, nous étions face à un code presque illisible car les variables, les noms des méthodes et les noms des classes étaient constitués avec des lettres de l'alphabet. Ce qui ne nous a pas beaucoup aidé pour la compréhension du code.
Seule la classe principale \textit{Checkers} est inchangée. Il nous a fallu donc étudier minutieusement chaque variable, méthode, classe et leurs relations pour pouvoir décrypter les noms.
\subsubsection{Les variables}
\begin{verbatim}
...
  private int q;
  private int r;
  private int S[];
  private int T[];
...
\end{verbatim}
  
\subsubsection{Les méthodes}
  \begin{verbatim}
...
  private final int a(boolean f){...}
  private final int a(boolean l, int a,int b){...} 
  private final int a(boolean g1, int a1, int a2){...}
  private final int a(boolean j, int a){...}
...
  \end{verbatim}
\newpage
\subsubsection{Les classes}
\begin{verbatim}
public class Checkers extends Activity {
	private b view;
	...  
}
public class b extends View {...} //classe CheckersView

public class a extends {...} //classe de la ControleurView
\end{verbatim}
